「三分是什麼意思？」

昨天那三位評審，隔週被品管室請回來開共識會議。目的很單純：既然分數差那麼多，就把評分表拿出來一格一格對。第一個項目就卡住了。

我問：「三分是什麼意思？」

第一位：「該做的都做了，但沒有做深。」

第二位：「有明顯的缺漏，但不影響結論。」

第三位想了一下，說：「我通常是……給不出二分、也給不出四分的時候，就給三分。」

會議室安靜了幾秒，然後有人笑出來——因為大家都知道那是實話。

三分不是一個標準，是一個殘差。 它是所有無法歸類的判斷最後掉進去的那一格。而評分表上寫的是「尚可」——兩個字，什麼也沒說。

那天下午我們沒有改分數，改的是評分表。

錨點：把刻度寫成看得見的東西

品管界對這件事有個現成的解法，叫錨點（anchor）：把量表的每一個刻度，寫成一段可以拿去對照文件的敘述。

沒有錨點的量表，格子裡放的是形容詞：優、良、可、差。形容詞是同義反覆——「優」的意思是「很好」，「很好」的意思是「優」。有錨點的量表，格子裡放的是可觀察的特徵：文件裡有沒有出現某樣東西、某個步驟有沒有留下痕跡。

你們每天在寫同一種東西，叫驗收條件：

❌ 效能要好
✅ p95 延遲在 200 毫秒以下，連續七天

你早就知道第一句是廢話——只是在寫 prompt 的時候，很多人又寫回第一句。所以這一篇不會花時間教你「要寫得具體」。你已經會了。這篇要講的是你會了之後才會遇到的那些事。

先說一件事免得誤會：下面的示範我用 postmortem，不用院內那張圈報告評分表，原因跟 Day 22 那個「院內的不能用」一樣。但每一條原則我都會標出它在圈報告那張表上長什麼樣子。

示範的維度是：一份 postmortem 的「根因段落」品質，一到五分。

差別在哪？右欄的每一句都可以拿著文件去對，然後回答「有」或「沒有」。 左欄不行。

在圈報告那張表上，同一格長這樣：三分是「選定了要因，但沒有做驗證」，四分是「做了驗證，而且查檢表或現場觀察的結果寫在報告裡」。

先講壞消息：錨點寫得越細，判斷越退化成關鍵字比對

這是這件事上最反直覺的一個 trade-off。我把它放在最前面，因為後面所有的原則都要在它的陰影下讀。

錨點要具體，具體才可判定。但當你把「引用了至少一項當時的證據（log、監控、時間線）」寫進去，模型會開始做一件事：在文件裡找「log」「監控」這幾個字。 找到就給分——即使那句話的意思是「我們當時沒有可用的 log」。

換到我這邊一模一樣。錨點寫「有做真因驗證」，它就去找「驗證」兩個字；圈報告裡寫著「本圈討論驗證後認為無須查檢」，它照樣給四分。而那句話的意思，其實是沒有驗證。

方向很清楚：

錨點的細化，會把判斷穩定地往關鍵字比對那一端推。這不是隨機失誤，是可預期的退化——而且你寫得越努力，退得越徹底。

煞車只有一個，而且它必須跟錨點一起出廠：每一個分數都要引出它依據的那一句原文。 找不到句子，就不能給那個分數。

引出來的那句話會攤在你面前。一個給四分的理由寫「有引用監控證據」，證據句卻是「當時監控沒有涵蓋這段」，錯誤就無所遁形。稽核是同一條規矩：品管室不能只回一個「不合格」給單位，要指出病歷裡的哪一行。

所以錨點和證據句是一對：錨點讓模型判得動，證據句讓你看得出它判錯。 只有錨點沒有證據句，你會得到一個高一致性、高信心、而且悄悄在比對關鍵字的系統。

五條原則，壓成一頁

知道那個退化方向之後，剩下的原則就好講了。前四條你寫驗收條件的時候本來就在做，我只標出它在評分表上的變形：

一、寫可判定的文件特徵，不寫程度副詞。 「充分」「適當」「深入」「完整」在評分表上一律禁用，要寫成「文件裡有沒有出現 X」。

二、相鄰兩級之間必須有一個可指認的差異。 把三分和四分並排，問自己：哪一句話決定它是三分不是四分？ 上面那張表的答案是「有沒有引用當時的證據」——那句話就是三跟四之間那條線。答不出來的那幾組，就是你的分歧來源——那是 spec 裡的 TODO，只是沒有人標。

三、兩端先寫，中間最後寫。 多數人寫評分表是從一分往上加形容詞：差、尚可、良好、優良、卓越——這個順序註定寫出殘差型的中間級。正確的順序是先把五分寫死，再從五分往下扣：

5 分 = 根因有證據支持 + 有寫出排除了哪些替代解釋 + 對策直接對應到該根因
4 分 = 缺「排除替代解釋」
3 分 = 缺「排除替代解釋」，且根因沒有證據支持
2 分 = 只寫了直接觸發事件（誰改了什麼），沒有往下追
1 分 = 沒有根因段落，或只寫了「人為疏失」這類歸咎個人的結論

這樣寫出來的中間級，是「缺了什麼」而不是「有多好」。缺什麼可以指認，有多好不行。一分那條的「歸咎個人」不是隨手寫的——那是 Day 13 行動強度階層的投影：把責任推到人身上是強度最低的結論。圈報告的一分也是同一條：對策欄寫「加強教育訓練」。

四、明文禁止跨維度推導。 這條要直接寫進 prompt，而且寫得很白：「評這個維度時只能引用與這個維度相關的內容，不得因為其他維度的表現而調整本維度的分數。」不寫的話，評分者會產生整體印象然後所有維度一起動——報告寫得漂亮、圖表精美，八個項目一起往上飄。這在人身上叫月暈效應，在模型身上更嚴重，因為它天生就在做「這份文件整體給我的感覺」。一旦所有維度連動，八個維度就退化成一個維度乘以八。你們的說法：test 之間不能互相依賴。

五、每一個分數都必須引出原文句子。 就是前面那個煞車。

第六條：需要外部知識的維度，錨點救不了

這是六條裡最難、也最值得寫的一條，因為它是唯一一條你寫驗收條件的經驗幫不上忙的。

維度分兩種：

• 文本內可判定 — 答案就在文件裡：有沒有引證據、有沒有寫排除的替代解釋。錨點寫好就夠
• 需要外部知識 — 答案不在文件裡，評分者要自己補一段判斷：「這類事故多常發生」「這個對策在病房實不實際」

昨天講過，模型之間的不一致集中在第二種維度上，原因是每個模型帶著各自的先驗知識，而我沒有給它們共同的基準。

錨點在這裡幫不上忙，因為錨點描述的是「幾分長什麼樣」，不是「這件事實際上是什麼情況」。你要補的是後者——一張參考表：把這個維度需要的外部知識整理成分類、每一類對應哪一級、依據是什麼。

寫參考表有三條規矩，缺一不可：

1. 有優先序 — 案例本身有資訊，以案例為準；沒有才查表；表上沒有的找最接近的類別，並在輸出裡註明是查表推估
2. 標依據 — 每一類的分級依據要註明來源（公開年報、文獻、院內共識）。不標，這張表就是一個沒人能質疑也沒人能維護的黑箱
3. 禁止交叉推導 — 明文寫「不得因為後果嚴重就推論它常發生」。這種推導人和模型都會做，而且做得很自然

第二條最容易被跳過，而它是三條裡最貴的：一張沒有標依據的參考表，就是一份沒有 commit message 的常數表——半年後沒有人敢動它，也沒有人記得為什麼是這個數。

而這一條真正的意義，是它把昨天那句話變成一個具體的動作：

你要補的不是模型的能力，是它的輸入。

補上之後一致性會回來——回來的原因不是模型變聰明了，是你終於把該給的資訊給了。這個因果方向很重要，它決定你下次遇到同樣問題要去改哪裡。

以我這邊的例子講：要補的是「這一類事件在病房大概多常發生」。那件事從來沒有寫在圈報告裡，因為寫報告的護理師本來就知道——現場的常識是最不會被寫下來的那一種知識，而那正好是評分者最需要的那一種。

AI 側：錨點放進 prompt 之後

一次評全部，還是一個維度一次呼叫

我選 B，理由是第四條：維度隔離只靠一句「請不要跨維度推導」撐不住——把其他維度的錨點從 context 裡拿掉，比叫它不要看有效得多。 這是拿延遲換獨立性：你也願意讓 CI 慢五分鐘，換一組不會互相污染的 test。

C 是我最想提醒的一個。給範例的效果非常好，好到可疑——因為範例會變成新的錨點，而且權重比你辛苦寫的那幾百字大得多。模型會去模仿範例的分數分佈，而不是套用你的規則：你放了三份三分的圈報告當範例，它就開始傾向給三分。

判斷方法：把範例換成分數不同、但同樣合格的另一組，看分數會不會跟著動。會動，就代表它學的是範例不是規則。

錨點是 prompt 裡最像 code 的部分

錨點必須是版本化的資產，跟程式碼一樣管：有版本號、有 diff、有改動理由、有回歸測試。實際的迴圈長這樣：

錨點 v1.0 → 跑固定案例池 → 逐維度看一致性與分數分佈
   ↓
挑出最不一致的那個維度 → 讀它的分歧案例與理由文字
   ↓
判斷是「錨點沒寫清楚」還是「缺外部知識參考表」→ 改對應的那一段
   ↓
錨點 v1.1 → 重跑同一批案例 → 比對 v1.0
   ↓
只留下有改善、且沒有讓其他維度變差的版本

注意倒數第二行：要比對整張表，不能只看你想改的那個維度。 改一個維度的錨點常常會動到別的維度，尤其在你沒有嚴格做維度隔離的時候。這就是 regression，跟你們防的東西一模一樣。

而「沒有讓其他維度變差」這一行代表：你需要兩個版本在同一批案例上的完整結果，都留著。所以案例池要固定、輸出要存檔、每次跑都要記下用的是哪一版錨點、哪一個模型版本（Day 27 完整談）。沒有這些，你連「這次改得比較好」都證明不了。

錨點是 prompt 裡最像 code 的部分，也是最該被 code review 的部分。 它有明確的輸入輸出、有可驗證的行為、改壞了會有回歸——唯一不像 code 的地方是它用中文寫，所以每個人都覺得自己可以隨手改一下。

品管的評分標準本來是一份給人看、靠共識會議校準的文件；接上這條迴路之後，它變成一份有版本、有測試、有回歸的規格書。

規格書的歧義消除你們做過很多次。差別只在於，你們消除的是「這個功能要怎麼做」的歧義，我消除的是「這個判斷算幾分」的歧義。後面那種一直被認為消不掉，所以那一半的工作從來沒有自動化過。

五分鐘就能查完一整張表

明天上班可以做的一件事，不需要任何工具：

把你手上任何一張評分表——rubric、面試評分表、code review checklist、圈報告評分表都行——的相鄰兩級並排，逐組問一句：哪一句話決定它是三分不是四分？

一張八個項目、五個級距的表有三十二組相鄰級距。全部問一遍，答不出來的那幾組，就是你團隊每次吵架的地方。

要吵的地方先被圈出來，共識會議才吵得完。

明天談一個更根本的問題：這些判準寫好之後，我怎麼知道它真的抓得到問題？